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The Mission Operations Support Area has been designed 
utilizing numerous commercial off the shelf items (see 
Figure 1), when possible, providing ease of maintenance 
and upgrade-ability. At its inception, all equipment was 
at the fore-front of technology. The system was created 
to provide the operator with a 'State of the Art' 
replacement for equipment that was becoming antiquated 
and virtually impossible to repair with new parts 
because of unavailability. Although the Mini-NOCC 
provided adequate support to the Network for a number of 
years, it was quickly becoming ineffectual for higher 
data rate and non-standard missions. The MOSA will prove 
to be invaluable in the future as more and more missions 
require Ground Network support . 


For the past several years, NASA has provided Operational and 
Technical support to its Ground stations utilizing the Mini- 
NOCC telemetry, command, tracking, range safety, and 
log/delog data systems shown in Figure 2. Specific functions 
include, station sub-system verification, system 
verification. Mission support verification, personnel 
proficiency training, mission support validation, and pre- 
mission, mission, and post mission fault isolation and 
analysis. These functions are provided for Space Shuttle, 
Expendable Launch Vehicles (ELV) , and their payloads as well 
as station changes and upgrades. 


Early in 1990 the Small Explorer project requested the 
assistance of the Networks Division in providing these 
support functions for a series of ground supported high data 
rate CCSDS compatible payloads. With the current Mini-NOCC 
being restricted to 224kb data streams and unable to process 
CCSDS recommendations, it was evident that not only a more 
enhanced data system would need to be developed to meet these 
requirements, but this new system must be designed and 
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Figure 2 . Mini-NOCC Configuration 











implemented in a relatively short period of time in order to 
meet the established SMEX mission manifest. With a challenge 
of this magnitude, it was decided that a team of qualified 
engineers from both NASA and AlliedSignal Technical Services 
(ATSC) be formed to tackle the project. Thus came in to 
being, the Mission Operations Support Area (MOSA) . 

After investigating all avenues, a final design was agreed 
upon. The design, as reflected in Figure 3, consisted of 
multiple workstations tied together via an Ethernet interface 
to an intelligent Front End Processor controlling all 
incoming and outgoing data. Each workstation would consist of 
a Macintosh or PC based system with dedicated video monitors . 
Ten identical Macintosh workstations would be utilized as the 
basic support system providing telemetry, command, and track 
functions. The log/delog system would be comprised of two 
Northgate 486 PC's and hard drives capable of logging lGBytes 
of data. In addition to these workstations, it was decided to 
incorporate another to act as a system file server that could 
be used as a massive system data base providing multiple 
system and program aides. To accommodate the system, new 
consoles had to be designed and fabricated. And to further 
assist in meeting the projected mission timeline, the 
decision was made to relocate the MOSA instead of interfering 
with ongoing mission support in the Mini-NOCC. 

The following paragraphs describe in high level detail 
individual MOSA sub-systems and their relationship to each 
other and the overall system concept. 

MOSA COMMUNICATIONS PROCESSQB 

The MOSA Communications Processor (MCP) provides the 
interface to all external Nascom circuits. Two redundant 
MCP ' s were developed around a Motorola 32MHz MC68030 
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Figure 3 . MOSA Detailed Block Diagram 










microprocessor with 16 Mbytes of RAM for subsystem 
communication. Of the two processors within each MCP, 
reference Figure 4, one acts as the master controller while 
the other is the slave. The master processor controls all 
communications to the workstations, maintains the subsystem 
data requests, and controls the status and diagnostic 
displays at each console. The slave processor analyzes the 
data as it is received, builds the frames of data for 
display, receives the asynchronous tracking data, and 
coordinates diagnostic testing. The MCP stores the analyzed 
data internally and provides it to the workstation upon 
request . 

The operator control of the MCP is provided by touch screens. 
The touch screens are composed of plasma displays with 
infrared sensors located around the perimeter of the screen 
for sensing the menu selection made by the operator. The 
touch screens are located not only on the front of the MCP 
but also remotely from each console position. All touch 
screen functions are available, regardless of which display 
the operator utilizes. The MCP initializes the touch screen 
with the MCP identification number, the software version, the 
current GMT, provided by the internal Bancomm timing 
decoders, and the elapsed time from MCP activation. The MCP 
identifies which Macintosh workstations are currently 
configured to the MCP along with an incrementing counter for 
network messages transmitted to and received from the 
workstation. The same display will provide the time at which 
the Macintosh activated the connection and the number of 
windows active at that position. The system errors are 
displayed at the bottom of the main screen but can be 
expanded to thirteen lines with scrolling capabilities. The 
errors are identified and tagged with corresponding block 
time. The diagnostic display provides an analysis of the 
Intelligent Transmit/Receive boards. The test is configured 
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Figure 4 . MCP Configuration 
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with a specific transmit port, receive port, clock rate, and 
receiver time out. The system performs a bit error rate 
check on the ports and delivers the results to the operator 
for analysis. The data connection display identifies which 
of the Input/Output (I/O) ports are active according to the 
stream name and/or clock activity. In addition to counting 
the number of elements received and transmitted, the MCP 
counts the number of Cyclic Redundancy Check (CRC) errors 
received on each channel. The system is capable of 
resynchronizing a stream of telemetry data in any standard 
format as well as CCSDS data up to 1.544 Mb/second. The MCP 
is capable of handling up to eight full duplex Nascom lines . 

Within the MCP, Intelligent Transmit /Receive (ITR) boards are 
installed to provide an interface to Nascom equipment . These 
boards, designed and developed by NASA, communicate channel 
activity to the MCP ' s and to the workstations. The 
configuration is demonstrated in Figure 5. Each board 
provides full duplex synchronous channels for interfacing to 
NASCOM and resynchronizing telemetry. The board is a Harris 
RTX2000 micro controller programmed in Forth assembly 
language. Each transmit board can handle synchronous blocks 
up to 65536 bytes in length. This makes the boards practical 
for both Nascom blocked data and telemetry frames. CRC 
polynomials are generated by the ITR and inserted at the end 
of the Nascom blocks and telemetry frames. The transmit (or 
receive) clock can be externally supplied, internally created 
by the frequency synthesizer, or from a selected clock on 
another transmitter. The ITR receive capability is also 
65536 bytes in length. Two 64-bit digital correlators allow 
detection of the selected synchronization pattern with 
programmable data and mask patterns and an allowable number 
of errors. The correlators operate in parallel to allow the 
detection of both true and inverted frame sync patterns. The 
receive channel on the ITR will also detect and correct for a 


90 


> 5 ID DO 3 CO CL OJ 



>2UJ CO 3 CO Q. r- 


91 


Figure 5. ITR Block Diagram 













bit slippage of up to one bit in either direction. Receive 
CRC or Nascom polynomial errors are detected and reported to 
the MCP. 

MOSA WORKSTATIONS 

The Apple Quadra workstations replace the Apple lie and IBM 
computers in the Mini-NOCC. The workstation is the primary 
operator interface in the MOSA data system. The operating 
system is Apple Computer's System 7. The MOSA software 
developed by NASA is the processing software that allows the 
user to interact with the database/server, log/delog, and 
MCP. The software was developed utilizing MacApp and C++ 
along with the importation of applications previously 
developed for existing station equipment. Upon launching the 
MOSA icon, an MCP connection must be chosen. If the operator 
later wishes to connect to the other MCP, the MOSA 
application must be ended and restarted. No connection is an 
option if the user is creating and storing data monitoring 
configurations for future use. 

The MOSA software is a combination of all the functions 
previously supported by the Mini-NOCC (with the exception of 
Air-to-Ground) . The operations are sorted into Block, 
Telemetry, Shuttle, CCSDS, Acquisition/Track, Range Safety, 
Command and general status information. Whenever a 
processing window is selected from the menus, the operator is 
prompted for the stream configuration information. The 
amount of parameter information requested depends upon the 
level of analysis. 

The Block function processes Nascom 4800 bit blocks. A block 
show will display all blocks which meet the configuration 
criteria starting with the Nascom sync pattern. The scroll 
bars enable the user to examine the block in its entirety. 
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The block statistics window will process the indicated Nascom 
blocks and provide summary information. The information 
includes the number of blocks accepted, PEP errors, sequence 
errors, missed blocks, delta time errors, and Nascom frame 
sync bit errors. Counters in any statistic window can be 
reset individually or globally. 

The Telemetry operation includes a frame show which displays 
the frame time and the raw frame starting at the frame sync. 
The telemetry frame statistics window processes the selected 
stream and indicates lock status, inversion, frames expected, 
frames accepted, true/inverted syncs, sync dropouts and frame 
sync errors. These two windows are specifically for 
throughput telemetry. 

To support the shuttle program, several shuttle specific 
displays are required. An Operational Downlink (OD) show 
window displays the telemetry with subframe information. The 
Space Shuttle Main Engine (SSME) analysis tracks the number 
of valid frames and errors received for each engine along 
with a display of the frame its self. A statistical display 
of the data received from the stations gives the operator a 
quick view of the station performance. On another set of 
displays, the command, telemetry, and track site status 
messages (SSM's) are translated in alphanumeric values and 
displayed in full by scrolling through the window. 

The CCSDS functions include both telemetry and command 
processing. The telemetry frame show and telemetry frame 
statistics windows are comparable to the throughput telemetry 
windows described previously. The CCSDS telemetry frame 
statistics window additionally includes counters for the 
number of frames and packets received relative to their 
virtual channel identifier. The telemetry frame header, 
telemetry packet header, command frame header, and command 
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packet header windows translate the header information into 
alphanumeric information based upon the corresponding CCSDS 
standard. The telemetry frame show, telemetry packet show, 
command frame show, and command packet show display the 
selected segment (frame and packet) of raw data for the given 
stream. The telemetry packet statistics displays the biock, 
frame, and packet times along with the quantity of each 
application ID received in the telemetry stream. Once 
enabled, the lock/search history will annotate the actual GMT 
times for lock and loss of lock on a designated stream. The 
Command Link Transmission Unit (CLTU) statistics evaluates 
the telemetry stream. The CLTU portion of the stream is 
translated while the number of blocks received and the number 
of invalid CLTU's are counted. The Command Link Control Word 
(CLCW) display provides the parameters in alphanumeric 
symbols. The scrolling portion of the display contains the 
CLCW in raw format with GMT of receipt. Finally, the command 
history window contains a scrolling area for listing the 
command application ID, the commanded function ID, and the 
block time of the command. 

The Acquisition/Track function processes all incoming 
tracking data for selection by the operator. The track 
status window indicates which tracking data types are being 
received and from which station the data originated. Valid 
data is written in green. A stream that has dropped out or 
has been interrupted will go to red for two minutes, then the 
stream will drop from the display list. An invalid LTAS 
stream will be displayed in black with only the valid bits 
displayed. Clicking on one of these listed streams will 
activate the tracking summary window. The track or Launch 
Trajectory Acquisition System (LTAS) summary window will 
translate the data selected into detailed alphanumeric 
displays. The summary windows can also be accessed directly 
from the Acq/Trk menu. If the window is selected from the 
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menu, the operator will be requested to choose the data for 
processing from a list of incoming streams. The options 
window allows the operator to select the parameter units for 
range, Doppler, and the angle coordinates. The track 
comparison window prompts the operator to select an 
acquisition message with which to compare the incoming 
tracking data. The message is computed and derived for the 
relative time found in the tracking data and then parameters 
are compared to the incoming station data. The transmit 
acquisition message window allows the selection of an 
acquisition message from the server database. The operator 
then selects which destination router is necessary for this 
message. The transmit button enables the sending routine. 

Range safety processing is a detailed analysis of the 2.4 Kb 
streams utilized during ELV and Shuttle supports. The data 
is evaluated and displayed in alphanumeric format to enable 
rapid realtime analysis. The parameters are specified with 
the appropriate units. This function also has the capability 
to display the analog parameters within the stream as digital 
Cathode Ray Tube (CRT) strip chart signals. This process was 
originally performed with physical analog strip chart 
equipment provided specifically for this task. 

Scientific spacecraft commanding allows the operator to 
transmit test commands to the stations and POCC ' s for 
verification. The commands are designed and created by the 
operator to match the POCC command structure. The transmit 
window will also confirm the validity of the station's 
command echo block. The Shuttle command function provides 
unencrypted modulation to the station and locks on the 
station's command echo. The modulation can be clocked 
internally or externally. A transmit window sends a command 
through the modulation for verification in the command echo 
portion of the window. 
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Further functions adapted from other systems in existence 
include the error history and the watch panels. The error 
history tracks the processing errors reported by the MOSA 
software and the MCP along with the time of their occurrence. 
The watch panels allow the operator to select a specific bit 
or group of bits to monitor within the block, frame, or 
packet. This utility greatly reduces the time spent manually 
delogging data or trying to see bit values on a constantly 
updating show window. 

Unique capabilities are created under the MOSA software 
application. Since the capabilities are useful to all 
windows and operations, they are grouped under File and Tool 
menus. The MOSA software allows the user to configure a 
window and save the file under a descriptive name for use 
during operational support. When one opens a saved file, the 
software requests a confirmation of the configuration and 
then activates the window without additional entries. the 
print show operation will print to the Apple Laser writer the 
entire block or frame which is currently displayed in the 
active show window. The configure function supplies the 
configuration menu for the selected window in order to update 
the parameters for processing. Freeze/thaw will pause/ 
restart the processing of the active window. The refresh 
rate or how often a window is updated can be increased and 
decreased, although this function is also affected by the 
number of windows open on the workstation. Specific warning 
messages are provided by the MCP to the workstation to alert 
the operator when changes are made to the MCP that will 
effect the workstation's current operations. A function is 
available to disable the warning windows but an audible alarm 
is still provided. Finally, the MCP can be configured to 
allow the processor to lock on a frame sync with a few 
incorrect bits. This effects all block synchronization that 
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the MCP does and therefore, effects all other workstations 
configured to this processor. 

MOSA LOG/DELOG 

The MOSA Log/Delog element replaces the PDP-11/24 system 
originally used in the Mini-NOCC. Two Northgate 486DX 33MHz 
computers have the capability of logging Nascom blocked data 
and low speed teletype traffic. Each system contains two 
Nascom Interface Boards (NIB) and a timing board. the 
programs are created in a DOS environment with the Borland 
"C" compiler. The logger requires the use of MX, or 
Multitasking Executive, which was developed initially for the 
Telemetry and Communications Data System located at the NASA 
tracking stations in Bermuda and Merritt Island, Florida. 
This multitasking environment will allow the unit to log 
incoming data and also playback data, in separate operations, 
for the user. The 1 Gbyte hard disk drive is segmented for 
data storage. The high speed active area is used to log and 
store Nascom blocked data. This is the largest area since it 
is also designed to meet the requirement to log at least five 
minutes of 1.544 Mbyte data. The low speed active area is 
used to store the teletype tracking data. The last portion 
of the disk is set aside for the archive areas. These 
locations allow the operator to save previously logged data 
and prevent overwrite by another logging activity. Six of 
the archive areas are designed to hold 15 minutes of 224Kb 
data, and the seventh area is dedicated to protecting five 
minutes of the 1.544 Mb/second recorded data. An area has 
been allocated to provide directory information to the 
operating programs. The hardware allocation is designed to 
reduce time-consuming disk head movement and to reduce file 
segmentation . 
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To begin a logging operation, the user selects either a 
Nascom or serial port. For a Nascom port, the software 
identifies delimiters that may be set by the operator or left 
blank. This allows the system to identify selected blocks on 
a port that may be receiving multiple data streams from 
multiple sources. Start and stop times are selectable, 
otherwise, all blocks received, which meet the criteria, are 
logged. If the logging operation is at a T1 rate (1.544 
Mbytes), all other logging operations are canceled to 
dedicate all the system resources to the high rate operation. 
If a serial port is chosen for the logging operation, 
delimiters are not available and the system will promptly 
begin logging all data that arrives at that port. A message 
in the status area is provided to indicate when the active 
area is in danger of being overwritten. This allows the 
operator to write the data to an archive area before it is 
lost. The status area also briefly indicates which ports are 
logging and if any CRC errors were received at that input. 
The main menu provides a short display of all sessions in the 
high/low speed areas and a quick directory of the archive 
locations. A selection of one of the sessions or locations 
will provide a more detailed description including the 
delimiter parameters and the exact block times within the 
session . 

The playback operation simply places data from either the 
active or the archive areas directly to the MCP or on the 
system Ethernet for use at the MOSA workstations. After 
selecting a session ID or a specific archive area, the 
operator selects a port and the recorded start/stop times of 
the data to be transmitted. The playback can be set for 
transmission at the original rate of the data, the maximum 
rate for the port, or a user defined rate. For Nascom blocks, 
the option is available to use an external or an internal 
clock. If an internal clock is selected, several choices are 
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provided or the user can specify the rate. Nascom blocks can 
also be selected by header parameters (or delimiters) during 
playback. The status window will update to reflect the 
configuration for the playback with a continuous monitor 
until the activity is complete. 

To delog the data, a separate program is initiated. This 
program is again written in "C" language. The archive or 
active area is selected and the recorded start/stop times 
identified. For Nascom blocks, delimiters are available. 
The operator has the choice of reviewing the data on the 
screen, sending it to the printer, or both. The printing and 
display format is selectable between hexidecimal, decimal, or 
octal. A delog to the screen will display the configuration 
at the top of the screen and the blocked data below. The 
blocks can be stepped through manually or allowed to update 
at the system rate. Printouts are designed to ensure that a 
full block is displayed on one page for operator ease of 
analysis . 

MQSA FILE SERVER 

The MOSA File Servers are Macintosh Quadra 950 computers 
running the 4D Client application. The server is accessible 
remotely from any of the workstations. Each server is 
independent, but data files can be copied by the operator 
from one server to the other for backup purposes. The server 
stores databases and program lookup tables. The operator has 
the ability to review the databases and in specific instances 
update the information. To access these databases a server 
is selected, and the server will prompt the operator for a 
limited access password. The access level is determined by 
the system administrator. Once logged to the server, the 
port status window indicates the activity of the server 
serial port that is receiving the acquisition data or 
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teletype. The server status window annotates the number of 
messages received according to message class. These two 
windows provide evidence of the server's current standings. 
Under the database menu are the lookup tables and databases. 
Each of the database menu items allows the user to create, 
edit, review, and delete by record (according to access 
privileges) . 

The database concepts are particularly important for the 
tracking program. The tracking acquisition data is 
automatically stored into a database by way of the serial 
port . The outdated messages are deleted according to the 
same criteria utilized by the NASA Ground Network tracking 
systems documented in the STDN 724 . This database allows the 
user to update acquisition messages according to the needs of 
the operational environment. As a result, the system allows 
a retransmission of an acquisition message for purposes of 
exercising the station tracking and acquisition procedures 
and configurations, along with generating and transmitting 
test acquisition data. 

The lookup tables maintain information for the MOSA 
workstation software. The site geodetics, spacecraft 
ident i f ier/vehicle identifier, station mnemonics, teletype 
routers, and telemetry configuration parameters are all set 
values that are provided in lookup tables instead of 
requiring the operator to enter this data each time it is 
needed . 

The server also stores incoming teletype administrative 
messages. This database is utilized by the operators to 
retrieve Briefing Messages, Documentat ion Change Notices 
(DCN) , Software Support Instructions (SSI), Interim Support 
Instructions (ISI), and many other operational messages. The 
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teletype is distributed into relevant categories for easy 
access by any operator. 

Operational documentation is also stored on the server and 
updated with a word processor as changes are received. 
Therefore, the latest information is always available by 
accessing the systems server. 

In closing, the MOSA has been designed to enhance NASA's 
required support to the Ground Network system. The design 
will easily transition into normal system sustaining. In most 
cases the actual operators will be able to add functionality 
for new standardized missions. Though non-standard formats 
will require software and hardware modifications depending 
upon specific mission requirements. 
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